Proximity synchronizing audio gateway device

ABSTRACT

A digital audio gateway device for use in a wireless network of digital audio playback devices. The gateway device is wirelessly linked to one or more digital audio playback devices to provide a gateway to the Internet for the digital audio playback devices. In addition to functioning as a gateway, the device provides additional functionality and may act as a cache of digital audio data for the various digital audio players connected in the wireless network and may also act to automatically update digital audio content on the audio players, synchronize digital audio content and playlists between the digital audio players and continue automatically or upon user request a particular playlist as the user moves from one digital audio player to another.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.13/612,837 filed Sep. 13, 2012, which is now issued as U.S. Pat. No.9,712,371, entitled “CONTINUOUS DIGITAL CONTENT PRESENTATION ACROSSMULTIPLE DEVICES” which is a continuation of Ser. No. 13/019,783 filedFeb. 2, 2011, entitled “Proximity Synchronizing Audio Gateway Device”which is a continuation of U.S. application Ser. No. 09/858,810, filedMay 16, 2001, which is now issued as U.S. Pat. No. 7,890,661, entitled“Proximity Synchronizing Audio Gateway Device.” Each of theaforementioned patent(s), and applications(s) are hereby incorporated byreference in their entirety.

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention relates to an audio gateway device and moreparticularly to an audio gateway device that is adapted to be used in anetwork of one or more digital audio playback devices which provides agateway to the Internet for such digital audio playback devices andprovides additional functionality such as synchronizing the digitalaudio content and playlists between the digital audio playback devices.

2. Description of the Prior Art

A multitude of different devices for digital audio playback are known.Handheld or portable audio players, mobile as well as fixed audioplayers are known. Examples of such handheld audio players are compactdisc (CD) players and MP3 players. Such mobile audio players includeaudio players, such as CD players, mounted in vehicles. Such mobileaudio players are known to be mounted either in-dash in the vehicle orin the case of conversion vans and recreational vehicles in ceiling ofthe vehicle. Examples of fixed digital audio playback devices includestand-alone players and rack players that are adapted to connect to ahome stereo system and to an AC power source.

Digital audio content from the Internet is known to be downloaded ontostorage devices, such as CDs, by way of a personal computer. SuchInternet-based digital audio content has also been downloaded ontoportable MP3 audio players. Although such systems allow selected digitalaudio content to be played when desired by the user, such systems onlyallow rather limited functionality. As such, various functions, such asinteraction, communication and synchronizing the digital content on aplurality of digital audio players must be done manually. Thus, there isa need for system for providing increased functionality of variousdigital audio players.

SUMMARY OF THE INVENTION

Briefly, the present invention relates to a digital audio gateway devicefor use in a wireless network of digital audio playback devices. Thegateway device is wirelessly linked to one or more digital audioplayback devices to provide a gateway to the Internet for the digitalaudio playback devices. In addition to functioning as a gateway, thedevice provides additional functionality and may act as a cache ofdigital audio data for the various digital audio players connected inthe wireless network and may also act to automatically update digitalaudio content on the audio players, synchronize digital audio contentand playlists between the digital audio players and continueautomatically or upon user request a particular playlist as the usermoves from one digital audio player to another.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other advantages of the present invention will be readilyunderstood with reference to the following specification and attacheddrawings wherein:

FIG. 1 is a block diagram of a digital audio communication system inaccordance with the present invention.

FIG. 2 is a block diagram of a digital audio gateway in accordance withthe present invention.

FIG. 3 is a block diagram of a wireless communication network whichincludes various digital audio players in accordance with the presentinvention.

FIG. 4 is a block diagram of a system which utilizes a personalcomputing platform for communicating with a plurality of audio players.

FIG. 5 is an alternate embodiment of the invention which illustrates theuse of a television set top box as a communication link forcommunicating with a plurality of digital audio players in accordancewith an alternate embodiment of the invention.

FIG. 6 is a block diagram of an alternate embodiment of the inventionwhich illustrates a communication system between a number of digitalaudio players and stand-alone audio gateway.

FIG. 7 is a block diagram of a communication network between variousdigital audio players in accordance with another aspect of the presentinvention.

FIG. 8 is a block diagram of the computing platform in accordance withthe present invention.

FIG. 9 is a block diagram of a stand-alone audio gateway in accordancewith the present invention.

FIG. 10 is a block diagram of a mobile digital audio player inaccordance with the present invention.

FIG. 11 is a block diagram of a fixed digital audio player in accordancewith the present invention.

FIG. 12 is a block diagram of a handheld or portable digital audioplayer in accordance with the present invention.

FIG. 13 is a block diagram of an automotive digital audio player inaccordance with the present invention.

FIG. 14 is a block diagram of a rack player in accordance with thepresent invention.

FIG. 15 is a block diagram of a stand-alone digital audio player inaccordance with the present invention.

FIG. 16 is a flow diagram of the audio gateway message handling inaccordance with the present invention.

FIG. 17 is a flow diagram of the audio gateway discovery in accordancewith the present invention.

FIG. 18 is a flow diagram of the audio gateway drop-out detection inaccordance with the present invention.

FIG. 19 is a flow diagram of the audio gateway content synchronizationin accordance with the present invention.

FIG. 20 is a flow diagram of the audio gateway playlist continuation inaccordance with the present invention.

FIG. 21 is a flow diagram of the player message handling in accordancewith the present invention.

FIGS. 22 and 23 are flow diagrams of the player discovery in accordancewith the present invention.

FIG. 24 is a flow diagram of the player drop-out detection in accordancewith the present invention.

FIG. 25 is a flow diagram of the player content synchronization inaccordance with the present invention.

FIGS. 26 and 27 are flow diagrams of the player playlist continuationfeature in accordance with the present invention.

DETAILED DESCRIPTION

The present invention is adapted to provide additional functionality ofdigital audio players. For example, in one embodiment, as illustrated inFIG. 1, a computing platform 103, for example, a personal computer, isused as a gateway to enable various digital audio players 115 and 116 tobe connected to the Internet or other computer network 102. In thisembodiment, the computing platform 103 may be configured to access oneor more servers 100 on the Internet or other computer network 102 thatcontain digital audio content and other information 101, such asartists, track names, album names, lyrics, and playlists, among otherthings. Though the computing platform 103 can act as a digital audioplayer by itself, in this embodiment of the invention, the computingplatform 103 acts as an audio gateway for various digital audio players115 and 116, and can additionally provide caching of the digital audiocontent and other information 101 for the digital audio players 115 and116 from the servers 100 that are connected to the computing platform103 through the Internet or other computer network 102. Using a wirelessnetwork or wireless communication platform 104, the computing platform103 is adapted to communicate with various digital audio players, suchas one or more mobile digital audio players 115 and fixed digital audioplayers 116 that are within range of the wireless network or wirelesscommunication platform 104 forming a local wireless network as generallyillustrated in FIG. 3.

Various devices are contemplated for use as audio gateways, for example,as shown in FIG. 2. In one embodiment, a personal computer 105 coupledto an internal or external wireless communication network or wirelesscommunication platform 104, for example, an access point 106, is used asan audio gateway. Alternatively, a set top box 107 with a wirelessnetwork or wireless communication platform 104, coupled to aconventional TV 108, may be used as an audio gateway. A stand aloneaudio gateway 109 may also be formed from a wireless network or wirelesscommunication platform 104. Other embodiments of an audio gateway arealso contemplated. For example, any device with a wireless network orwireless communication platform 104, either public or private, may beused.

In another embodiment of the invention, the computing platform 103 maybe configured to automatically synchronize, or upon request, copy, addor remove digital audio content and other information 101, such asplaylists, on mobile digital audio players 115 and fixed digital audioplayers 116. The computing platform 103 may also be used to controlmobile digital audio players 115 and fixed digital audio players 116 bychanging the current playlist or the currently playing digital audiocontent, among other things, on the mobile digital audio players 115 orfixed digital audio players 116.

In another embodiment of the invention as illustrated in FIG. 7, thesystem enables communication between various digital audio players, suchas the digital audio players 110-113. This embodiment may be alsoincorporated with a computing platform 103, for example, acting as agateway, as discussed above, or alternatively using the computingplatform 103 for synchronization among the various digital audio players110-113 or other functions, such as those discussed above.

Audio Gateway

FIGS. 4-6 represent an exemplary network configuration, utilizingdifferent audio gateways for enabling connection of the digital audioplayers 110-113 to the Internet or other computer network 102. Theseexamples are by no means the only possible configurations that supportthe invention and do not necessarily cover all aspects of the invention.

Personal Computer and Digital Audio Players Configuration

The first exemplary configuration, shown in FIG. 4, uses a personalcomputer 105 as the audio gateway. The personal computer 105 connects tothe Internet or other computer network 102 using a conventional networkinterface or modem 137. The personal computer 105 is thus able todownload digital audio content and other information 101 from the server100 (FIG. 1) connected to the Internet or other computer network 102.The digital audio content and other information 101, such as artists,track names, album names, lyrics, and playlists, can then be stored in apersistent storage 133 (FIG. 8), such as a hard drive, on the personalcomputer 105. The user can also create new playlists using the personalcomputer 105.

In this embodiment, a wireless access point 106 is used to access thewireless network or wireless communication platform 104. The wirelessnetwork or wireless communication platform 104 is used by the personalcomputer 105, acting as the audio gateway, to communicate with mobiledigital audio players 115 and fixed digital audio players 116. Thepersonal computer 105, using the wireless network or wirelesscommunication platform 104, is able to, either automatically or at userrequest, pass the digital audio content and other information 101,including new playlists, to mobile digital audio players 115 and fixeddigital audio players 116. If a fixed digital audio player 116, such asa stand-alone player 112 or a rack player 113 that connects to a stereo114, happens to be turned off at the time, then the personal computer105 is able to automatically detect the next time the fixed digitalaudio player 116 is turned on. When the personal computer 105 detectsthat a fixed digital audio player 116 has just turned on, then thepersonal computer 105 can pass the digital audio content and otherinformation 101 to the fixed digital audio player 116 at that time.Mobile digital audio players 115, such as automotive players 110 andhandheld players 111, may be out of range of the wireless network orwireless communication platform 104 during normal use. When a mobiledigital audio player 115 comes into range of the wireless network orwireless communication platform 104, the personal computer 105, actingas an audio gateway, can automatically detect the mobile digital audioplayer 115 and pass the digital audio content and other information 101at that time.

In addition, the personal computer 105 can, either automatically or uponuser request, determine the current playlist and current position withinthe playlist on a particular mobile digital audio player 115 or fixeddigital audio player 116. Then the personal computer 105 can propagatethis playlist information to any other mobile digital audio players 115and fixed digital audio players 116 that are on and in range. Thisallows a user to move from one mobile digital audio player 115 or fixeddigital audio player 116 to another mobile digital audio player 115 orfixed digital audio player 116 and automatically be able to continue thesame music and playlist in a seamless manner.

Set-Top Box and Digital Audio Players Configuration

Another exemplary configuration, shown in FIG. 5, uses a set-top box 107as the audio gateway. The set-top box 107 can connect to the Internet orother computer network 102 either through the same cable or by way of asatellite connection that provides the analog or digital audio or video151 (FIG. 8) that is passed to an audio or video playback device, suchas a television set 108, or through an internal or external networkinterface or modem 137. The set-top box 107 can thus download digitalaudio content and other information 101 from a server 100, connected tothe Internet or other computer network 102. The digital audio contentand other information 101, such as artists, track names, album names,lyrics, and playlists, can then be stored in persistent storage 133,such as a hard drive or flash memory, on the set-top box 107.

In this embodiment, a wireless network interface or wirelesscommunication interface 141 is used to handle the wireless network orwireless communication platform 104. The set-top box 107, acting as theaudio gateway, uses the wireless network or wireless communicationplatform 104 to communicate with mobile digital audio players 115 andthe fixed digital audio players 116. The set-top box 107, using thewireless network or wireless communication platform 104, is able to,either automatically or upon user request, pass the digital audiocontent and other information 101 to mobile digital audio players 115and fixed digital audio players 116.

If a fixed digital audio player 116, such as a stand-alone player 112 ora rack player 113 that connects to a stereo 114, happens to be turnedoff at the time, then the set-top box 107 is able to automaticallydetect the next time the fixed digital audio player 116 is turned on.When the set-top box 107 detects that a fixed digital audio player 116has just turned on, then the set-top box 107 can pass the digital audiocontent and other information 101 to the fixed digital audio player 116at that time. Mobile digital audio players 115, such as automotiveplayers 110 and handheld players 111, are typically out of range of thewireless network or wireless communication platform 104 during normaluse.

When a mobile digital audio player 115 comes into range of the wirelessnetwork or wireless communication platform 104, the set-top box 107,acting as an audio gateway, can automatically detect the mobile digitalaudio player 115 and pass the digital audio content and otherinformation 101 at that time. In addition, the set-top box 107 candetermine, either automatically or upon user request, the currentplaylist and current position within the playlist on a particular mobiledigital audio player 115 or fixed digital audio player 116. Then theset-top box 107 can propagate this playlist information to any othermobile digital audio players 115 and fixed digital audio players 116that are on and in range. This allows a user to move from one mobiledigital audio player 115 or fixed digital audio player 116 to anothermobile digital audio player 115 or fixed digital audio player 116 andautomatically be able to continue the same music and playlist in aseamless manner.

Stand-Alone Gateway and Digital Audio Players Configuration

Another exemplary configuration, shown in FIG. 6, uses a stand-aloneaudio gateway 109 as the audio gateway. The stand-alone audio gateway109 connects to the Internet or other computer network 102 using anetwork interface or modem 137. The stand-alone audio gateway 109 candownload digital audio content and other information 101 from a server100 connected to the Internet or other computer network 102. The digitalaudio content and other information 101, such as artists, track names,album names, lyrics, and playlists, can then be stored in persistentstorage 133, such as a hard drive or flash memory, on the stand-aloneaudio gateway 109. In this embodiment, a wireless network interface orwireless communication interface 141 (FIG. 8) is used to handle thewireless network or wireless communication platform 104. The wirelessnetwork or wireless communication platform 104 is used by thestand-alone audio gateway 109 to communicate with mobile digital audioplayers 115 and fixed digital audio players 116. The stand-alone audiogateway 109, using the wireless network or wireless communicationplatform 104, is able to, either automatically or at user request, passthe digital audio content and other information 101 to mobile digitalaudio players 115 and fixed digital audio players 116. If a fixeddigital audio player 116, such as a stand-alone player 112 or a rackplayer 113 that connects to a stereo 114, happens to be turned off atthe time, then the stand-alone audio gateway 109 is able toautomatically detect the next time the fixed digital audio player 116 isturned on. When the stand-alone audio gateway 109 detects that a fixeddigital audio player 116 has just turned on, then the stand-alone audiogateway 109 can pass the digital audio content and other information 101to the fixed digital audio player 116 at that time.

Mobile digital audio players 115, such as automotive players 110 andportable or handheld players 111, may be out of range of the wirelessnetwork or wireless communication platform 104 during normal use. When amobile digital audio player 115 comes into range of the wireless networkor wireless communication platform 104, the stand-alone audio gateway109 can automatically detect the mobile digital audio player 115 andpass the digital audio content and other information 101 at that time.

In addition, the stand-alone audio gateway 109 can, either automaticallyor upon user request, determine the current playlist and currentposition within the playlist on a particular mobile digital audio player115 or fixed digital audio player 116. Then the stand-alone audiogateway 109 can propagate this playlist information to any other mobiledigital audio players 115 and fixed digital audio players 116 that areon and in range. This allows a user to move from one mobile digitalaudio player 115 or fixed digital audio player 116 to another mobiledigital audio player 115 or fixed digital audio player 116 andautomatically be able to continue the same music and playlist in aseamless manner.

Local Wireless Network

In another embodiment, shown in FIG. 3, a local wireless network isformed which enables wireless communication between a host, such as apersonal computer 105, a stand alone audio gateway 109, a set top box107, and various digital audio players, such as mobile digital audioplayers 115, fixed digital audio players 116, a stand alone audiogateway 109 and a set top box 107, for example, configured in a startopography. As shown, various audio gateways are used to establish thenetwork. However, in this embodiment, audio gateways, which contain awireless network or wireless communication platform 104 as discussedabove, are used primarily for establishing network communication and mayor may not be connected to a remote server 100.

Wireless communications between the computing platform 103 and mobiledigital audio players 115 and fixed digital audio players 116, can bedone using industry standard wireless communications and networkingtechnology, such as Bluetooth, HomeRF, and IEEE 802.11. In addition,with respect to this invention, a proprietary wireless communicationstechnology may also be used for wireless communications. Use of thewireless network or wireless communication platform 104 by computingplatforms 103, mobile digital audio players 115, and fixed digital audioplayers 116 may be handled as an internal or external peripheral in theform of a wireless network interface or wireless communication interface141. The wireless network or wireless communication platform 104 mayalso require an external wireless access point 106 to handle orfacilitate wireless communications and to act as a bridge between thewireless network and wired networking connections, such as may be usedby a personal computer 105.

Communication Between Digital Audio Players

FIG. 7 illustrates a wireless network configuration which enablescommunication directly among various digital audio players without ahost. The various digital audio players, such as mobile digital audioplayers 115 and fixed digital audio players 116, use the same wirelessnetwork or wireless communication platform 104 that is used towirelessly communicate with the computing platform 103, to communicatewith each other. The wireless communication between the various digitalaudio players may be handled by an internal or external wireless networkinterface or wireless communication interface 141 (FIGS. 10 and 11) ineach of the disposed digital audio players. In this embodiment,communication between the various digital audio players include directlypassing digital audio content and other information 101, includingplaylists from, for example, one mobile digital audio player 115 orfixed digital audio player 116 to another.

Computing and Player Architectures

FIGS. 8 and 9 illustrate architectures for the computing platform andstand-alone audio gateway platforms. FIGS. 10-15 illustrate thearchitectures for the various digital audio player platforms. As shown,the architecture of the various platforms is similar. Thus, likereference numbers are used for like components for clarity.

Computing Platform

FIG. 8 illustrates the typical system architecture of a computingplatform 103, which can encompass anything from general-purpose devices,such as personal computers 105, to open fixed function devices, such asset-top boxes 107 or stand-alone audio gateways 109, among others. Ingeneral, the computing platform 103 has a main processor 130, such as anIntel Pentium III, for executing various software components. Thevarious software instructions are typically stored in read only memory,or ROM, or flash memory 136, or local storage 132. The local storage 132can consist of persistent storage 133, such as hard drives or flashmemory, or removable storage 134, such as floppy drives, CD-ROM drives,or DVD drives. The software instructions may be executed by the mainprocessor 130 directly from their storage location or loaded into randomaccess memory or RAM 135 to be executed from RAM 135 by the mainprocessor 130. The local storage 132 can also be used to cache digitalaudio content and other information 101.

The computing platform 103 uses a network interface or modem 137 toaccess servers 100 on the Internet or other computer network 102, inorder to download digital audio content or other information 101. Thenetwork interface or modem 137, for example, a 3COM Etherlink 10/100 PCInetwork interface card, may be connected internally or externally to thecomputing platform 103 using a system bus or peripheral bus 131. Thesystem bus and peripheral buses 131 are provided for connecting internaland external devices to the computing platform 103 in a standard manner.Typical system and peripheral buses 131 include Universal Serial Bus,commonly referred to as USB, IEEE 1394 bus, commonly referred to asFireWire, and Peripheral Connect Interface, commonly referred to as PCI.

The computing platform 103 also supports connection through a user inputinterface 142 to external or integrated user input devices 153, such askeyboards and mice. In order to provide for output to the user, thecomputing platform 103 may also contain a display controller 138, forexample, an NVIDIA Model No. GeForce2, which stores graphical data suchas windows, bitmaps and text. The display controller 138 outputs thegraphical data in a video output 150 format that is typically displayedto the user on a video monitor, television 108, or LCD panel. Inaddition to video output 150, the computing platform 103 can provideaudio output 152, which is handled by audio playback hardware 140.

For a computing platform 103 that is acting as a set-top box 107, thecomputing platform 103 will likely also contain an analog or digitalaudio and video decoder 139, for example, a C-Cube Model No. AViA 600,hereby incorporated by reference. The analog or digital audio and videodecoder 139 decodes the analog or digital audio or video 151 fromsources such as cable or satellite, and passes the audio output 152 andvideo output 150 to an audio and video playback device, such as atelevision set 108.

For wireless communication with other computing platforms 103, andvarious digital audio players, such as mobile digital audio players 115,and fixed digital audio players 116 on a wireless network or wirelesscommunication platform 104, the computing platform 103 uses an internalor external wireless network interface or wireless communicationinterface 141. It should be noted that a computing platform 103 is notlimited to the capabilities and features listed in this description, butmay contain a subset of the described features or may contain additionalcapabilities or features not listed.

Gateway Platform

FIG. 9 demonstrates some of the unique capabilities of the stand-aloneaudio gateway 109, though this example is by no means complete orexhaustive in its coverage of the possible options for a stand-aloneaudio gateway 109. In particular, the stand-alone audio gateway 109 actsas a fixed function device, whose main purpose is to be an audiogateway. The fixed function nature of the stand-alone audio gateway 109is unlike the personal computer 105, which exists as a general-purposecomputing device. The stand-alone audio gateway 109 is able to connectto the Internet or other computer network 102 using an internal orexternal network interface or modem 137. The stand-alone audio gateway109 is able to cache digital audio content and other information 101downloaded from a server 100 connected to the Internet or other computernetwork 102 into persistent storage 133, such as a hard drive, on thestand-alone audio gateway 109.

FIG. 9 illustrates a typical system architecture of the stand-aloneaudio gateway 109. In general, the stand-alone audio gateway 109 has amain processor 130 for executing various software components. Thevarious software components are typically stored in read only memory, orROM, or flash memory 136, or local storage 132. Local storage 132 canconsist of persistent storage 133, such as hard drives or flash memory,or removable storage 134 such as floppy drives, CD-ROM drives, or DVDdrives. The software components are executed by the main processor 130directly from their storage location or are loaded into random accessmemory or RAM 135, to be executed from RAM 135 by the main processor130. Local storage 132 can also be used to cache digital audio contentand other information 101. The stand-alone audio gateway 109 uses anetwork interface or modem 137 to access servers 100 on the Internet orother computer network 102, in order to download digital audio contentor other information 101. The network interface or modem 137 isconnected internally or externally to the stand-alone audio gateway 109using a system bus or peripheral bus 131. The system bus and peripheralbuses 131 are provided for connecting internal and external devices tothe stand-alone audio gateway 109 in a standard manner. Typical systemand peripheral buses 131 include Universal Serial Bus, commonly referredto as USB, IEEE 1394, commonly referred to as FireWire, and PeripheralConnect Interface, commonly referred to as PCI. The stand-alone audiogateway 109 also supports connection through a user input interface 142to external or integrated user input devices 153, such as buttons,keyboards and mice. For output to the user, the stand-alone audiogateway 109 may contain a display controller 138, which stores displaydata such as windows, bitmaps and text. The display controller 138outputs the display data in a video output 150 format that is typicallydisplayed to the user on a video monitor, television 108, or LCD panel.In addition to video output 150, the stand-alone audio gateway 109 canprovide audio output 152, which is handled by audio playback hardware140. For wireless communication with mobile digital audio players 115,and fixed digital audio players 116 on a wireless network or wirelesscommunication platform 104, the stand-alone audio gateway 109 uses aninternal or external wireless network interface or wirelesscommunication interface 141. It should be noted that a stand-alone audiogateway 109 is not limited to the capabilities and features listed inthis description, but may contain a subset of the described features ormay contain additional capabilities or features not listed.

Mobile Player

Many different types of mobile digital audio players 115 are suitablefor use with the present invention. FIG. 10 demonstrates the generalarchitecture for a mobile digital audio player 115. In general, a mobiledigital audio player 115 has a processor 155 that is responsible forexecuting various software and firmware components. The various softwareand firmware components are typically stored in read only memory, orROM, or flash memory 158 or in player storage 156, such as a hard drive,flash memory, or removable media. The software and firmware componentsare executed by the processor 155 directly from their storage locationor are loaded into random access memory or RAM 157 to be executed fromRAM 157 by the processor 155. Player storage 156 can also be used forstoring digital audio content and other information 101, such asartists, track names, album names, lyrics, and playlists, for laterplayback and presentation to the user. Typically, the digital audiocontent 101 is in some encoded format. The audio decoder 162 decodes thedigital audio content 101 and passes it to the audio digital to analogconverter 163, or DAC. The audio DAC 163 converts the decoded audio toanalog and then provides audio output 166 from the mobile digital audioplayer 115. The audio output 166 of a mobile digital audio player 115 istypically passed to an amplifier or headphones. Communication using awireless network or wireless communication platform 104 by the mobiledigital audio player 115 with a computer platform 103, other mobiledigital audio players 115, and fixed digital audio players 116 is doneusing an internal or external wireless network interface or wirelesscommunication interface 141. For input from the user, the mobile digitalaudio player 115 contains user inputs 165, such as buttons or a touchscreen. The user input interface 164 handles the actual interface withthe user inputs 165, while interpretation of these inputs are typicallyhandled by software and firmware running on the processor 155. Foroutput to the user, the mobile digital audio player 115 may contain adisplay controller 160, which can provide text and possibly graphicaloutput to the user on an LCD display 161. Tying of the functionalcomponents and processor 155 together is typically done using a systembus and peripheral buses 159. Examples of system and peripheral buses159 include Universal Serial Bus, commonly referred to as USB, IEEE1394, commonly referred to as FireWire, and Peripheral ConnectInterface, commonly referred to as PCI. It should be noted that some ofthe functional blocks described might encompass multiple physicalcomponents. As well, multiple functional blocks may be contained in asingle physical component. It should also be noted that a mobile digitalaudio player 115 is not limited to the capabilities and features listedin this description, but may contain a subset of the described featuresor may contain additional capabilities or features not listed.

Fixed Player

There are many different types of fixed digital audio players 116. FIG.11 demonstrates the general architecture for a fixed digital audioplayer 116. In general, a fixed digital audio player 116 has a processor155 that is responsible for executing various software and firmwarecomponents. The various software and firmware components are typicallystored in read only memory, or ROM, or flash memory 158 or in playerstorage 156, such as a hard drive, flash memory, or removable media. Thesoftware and firmware components are executed by the processor 155directly from their storage location or are loaded into random accessmemory or RAM 157 to be executed from RAM 157 by the processor 155.Player storage 156 can also be used for storing digital audio contentand other information 101, such as artists, track names, album names,lyrics, and playlists, for later playback and presentation to the user.Typically, the digital audio content 101 is in some encoded format. Theaudio decoder 162 decodes the digital audio content 101 and passes it tothe audio digital to analog converter 163, or DAC. The audio DAC 163converts the decoded audio to analog and then provides audio output 167from the fixed digital audio player 116. The audio output 167 of a fixeddigital audio player 116 is typically passed to a stereo, amplifier,speakers or headphones. Communication using a wireless network orwireless communication platform 104 by the fixed digital audio player116 with a computing platform 103, mobile digital audio players 115, andother fixed digital audio players 116, is done using an internal orexternal wireless network interface or wireless communication interface141. For input from the user, the fixed digital audio player 116contains user inputs 165, such as buttons or a touch screen. The fixeddigital audio player 116 may also receive infrared input 168 from aremote control. The user input interface 164 handles the actualinterface with the user inputs 165 and the infrared input 168, whileinterpretation of these inputs are typically handled by software andfirmware running on the processor 155. For output to the user, the fixeddigital audio player 116 may contain a display controller 160, which canprovide text and possibly graphical output to the user on an LCD display161. Tying of the functional components and processor 155 together istypically done using a system bus and peripheral buses 159. Examples ofsystem and peripheral buses 159 include Universal Serial Bus, commonlyreferred to as USB, IEEE 1394, commonly referred to as FireWire, andPeripheral Connect Interface, commonly referred to as PCI. It should benoted that some of the functional blocks described might encompassmultiple physical components. As well, multiple functional blocks may becontained in a single physical component. It should also be noted that afixed digital audio player 116 is not limited to the capabilities andfeatures listed in this description, but may contain a subset of thedescribed features or may contain additional capabilities or featuresnot listed.

Handheld Player

Many different types of mobile digital audio players 115 are suitablefor use with the present invention. For example, FIG. 12 illustrates thegeneral architecture for the handheld player 111. In general, thehandheld player 111 includes a processor 155 for executing varioussoftware and firmware instructions. The various software and firmwareinstructions may be stored in read only memory, or ROM, or flash memory158 or in player storage 156, such as a hard drive, flash memory, orremovable media. The software and firmware instructions are executed bythe processor 155 directly from their storage location or are loadedinto random access memory or RAM 157 to be executed from RAM 157 by theprocessor 155. Player storage 156 can also be used for storing digitalaudio content and other information 101, such as artists, track names,album names, lyrics, and playlists, for later playback and presentationto the user. Typically, the digital audio content 101 is in some encodedformat. The audio decoder 162, for example, a Texas Instruments digitalsignal processor, Model No. TMS320VC5416, decodes the digital audiocontent 101 and passes it to the audio digital to analog converter 163,or DAC. The audio DAC 163, for example, a Texas Instruments Model No.TLC320AD77C converts the decoded audio to analog and then provides audiooutput 166 from the handheld player 111. The audio output 166 of ahandheld player 111 may be used to drive headphones.

Communication using a wireless network or wireless communicationplatform 104 by the handheld player 111 with the computing platforms103, other mobile digital audio players 115, and fixed digital audioplayers 116 is done using an internal or external wireless networkinterface or wireless communication interface 141. For input from theuser, the handheld player 111 contains user inputs 165, such as buttonsor a touch screen. The user input interface 164 handles the actualinterface with the user inputs 165, while interpretation of these inputsare typically handled by software and firmware running on the processor155. For output to the user, the handheld player 111 may contain adisplay controller 160, for example, an embedded display controller in aMotorola MC68EZ328 controller, which can provide text and possiblygraphical output to the user on an LCD display 161. Tying of thefunctional components and processor 155 together is typically done usinga system bus and peripheral buses 159. Examples of system and peripheralbuses 159 include Universal Serial Bus, commonly referred to as USB,IEEE 1394, commonly referred to as FireWire, and Peripheral ConnectInterface, commonly referred to as PCI. It should be noted that some ofthe functional blocks described might encompass multiple physicalcomponents. As well, multiple functional blocks may be contained in asingle physical component. It should also be noted that a handheldplayer 111 is not limited to the capabilities and features listed inthis description, but may contain a subset of the described features ormay contain additional capabilities or features not listed.

Automotive Player

Another type of mobile digital audio player 115 is the automotive player110, whose general architecture is shown in FIG. 13. In general, theautomotive player 110 includes a processor 155 that is responsible forexecuting various software and firmware instructions. The varioussoftware and firmware components are typically stored in read onlymemory, or ROM, or flash memory 158 or in player storage 156, such as ahard drive, flash memory, or removable media. The software and firmwareinstructions are executed by the processor 155 directly from theirstorage location or are loaded into random access memory or RAM 157 tobe executed from RAM 157 by the processor 155. Player storage 156 canalso be used for storing digital audio content and other information101, such as artists, track names, album names, lyrics, and playlists,for later playback and presentation to the user.

Typically, the digital audio content 101 is in some encoded format. Theaudio decoder 162 decodes the digital audio content 101 and passes it tothe audio digital to analog converter 163 or DAC. The audio DAC 163converts the decoded audio to analog and then provides audio output 167from the automotive player 110. The audio output 167 of an automotiveplayer 110 typically feeds a conventional audio amplifier, which thendrives the car speakers. Communication using a wireless network orwireless communication platform 104 by the automotive player 110 withcomputing platforms 103, other mobile digital audio players 115, andfixed digital audio players 116 is done using an internal or externalwireless network interface or wireless communication interface 141.

For input from the user, the automotive player 110 contains user inputs165, such as buttons or a touch screen. The user input interface 164handles the actual interface with the user inputs 165, whileinterpretation of these inputs are typically handled by software andfirmware running on the processor 155. In addition, an automotive player110 may support voice commands for user input. If voice commands aresupported, a microphone 174 is used to feed analog audio to the audioanalog to digital converter 173, which converts the analog audio todigital. Then, the audio capture hardware 172 and the processor 155 willinterpret the voice commands from the user. For output to the user, theautomotive player 110 may contain a display controller 160, which canprovide text and possibly graphical output to the user on an LCD display161. Tying of the functional components and processor 155 together maybe accomplished by way of a system bus and peripheral buses 159.Examples of suitable system and peripheral buses 159 include UniversalSerial Bus, commonly referred to as USB, IEEE 1394, commonly referred toas FireWire, and Peripheral Connect Interface, commonly referred to asPCI.

It should be noted that some of the functional blocks described mightencompass multiple physical components. As well, multiple functionalblocks may be contained in a single physical component. It should alsobe noted that an automotive player 110 is not limited to thecapabilities and features listed in this description, but may contain asubset of the described features or may contain additional capabilitiesor features not listed.

Rack Player

There are many different types of fixed digital audio players 116. FIG.14 demonstrates the general architecture for a rack player 113. Ingeneral, a rack player 113 includes a processor 155 that is responsiblefor executing various software and firmware instructions. The varioussoftware and firmware instructions may be stored in read only memory, orROM, or flash memory 158 or in player storage 156, such as a hard drive,flash memory, or removable media. The software and firmware instructionsmay be executed by the processor 155 directly from their storagelocation or loaded into random access memory or RAM 157 to be executedfrom RAM 157 by the processor 155. Player storage 156 can also be usedfor storing digital audio content and other information 101, such asartists, track names, album names, lyrics, and playlists, for laterplayback and presentation to the user. Typically, the digital audiocontent 101 is in some encoded format. The audio decoder 162 decodes thedigital audio content 101 and passes it to the audio digital to analogconverter 163, or DAC. The audio DAC 163 converts the decoded audio toanalog and then provides audio output 167 from the rack player 113. Theaudio output 167 of a rack player 113 typically is passed to a stereosystem 114. Communication using a wireless network or wirelesscommunication platform 104 by the rack player 113 with computingplatforms 103, mobile digital audio players 115, and other fixed digitalaudio players 116 is done using an internal or external wireless networkinterface or wireless communication interface 141. For input from theuser, the rack player 113 contains user inputs 165, such as buttons or atouch screen. The rack player 113 may also receive infrared input 168from a remote control. The user input interface 164 handles the actualinterface with the user inputs 165 and the infrared input 168, whileinterpretation of these inputs are typically handled by software andfirmware running on the processor 155. For output to the user, the rackplayer 113 may contain a display controller 160, which can provide textand possibly graphical output to the user on an LCD display 161. Tyingconnection of the functional components and processor 155 together maybe accomplished by way of a system bus and peripheral buses 159.Examples of suitable system and peripheral buses 159 include UniversalSerial Bus, commonly referred to as USB, IEEE 1394, commonly referred toas FireWire, and Peripheral Connect Interface, commonly referred to asPCI.

It should be noted that some of the functional blocks described mightencompass multiple physical components. As well, multiple functionalblocks may be contained in a single physical component. It should alsobe noted that a rack player 113 is not limited to the capabilities andfeatures listed in this description, but may contain a subset of thedescribed features or may contain additional capabilities or featuresnot listed.

Stand-Alone Player

Another type of fixed digital audio player 116 is the stand-alone player112, whose general architecture is shown in FIG. 15. In general, astand-alone player 112 includes a processor 155 that is responsible forexecuting various software and firmware instructions. The varioussoftware and firmware components are typically stored in read onlymemory, or ROM, or flash memory 158 or in player storage 156, such as ahard drive, flash memory, or removable media. The software and firmwarecomponents are executed by the processor 155 directly from their storagelocation or are loaded into random access memory or RAM 157 to beexecuted from RAM 157 by the processor 155. Player storage 156 can alsobe used for storing digital audio content and other information 101,such as artists, track names, album names, lyrics, and playlists, forlater playback and presentation to the user. Typically, the digitalaudio content 101 is in some encoded format. The audio decoder 162decodes the digital audio content 101 and passes it to the audio digitalto analog converter 163, or DAC. The audio DAC 163 converts the decodedaudio to analog. The analog audio from a stand-alone player 112typically directly drives speakers 170 attached to the stand-aloneplayer 112. Communication using a wireless network or wirelesscommunication platform 104 by the stand-alone player 112 with computingplatforms 103, mobile digital audio players 115, and other fixed digitalaudio players 116 is done using an internal or external wireless networkinterface or wireless communication interface 141. For input from theuser, the stand-alone player 112 contains user inputs 165, such asbuttons or a touch screen. The stand-alone player 112 may also receiveinfrared input 168 from a remote control. The user input interface 164handles the actual interface with the user inputs 165 and the infraredinput 168, while interpretation of these inputs are typically handled bysoftware and firmware running on the processor 155. For output to theuser, the stand-alone player 112 may contain a display controller 160,which can provide text and possibly graphical output to the user on anLCD display 161. Connection of the functional components and processor155 together is typically done using a system bus and peripheral buses159. Examples of suitable system and peripheral buses 159 includeUniversal Serial Bus, commonly referred to as USB, IEEE 1394, commonlyreferred to as FireWire, and Peripheral Connect Interface, commonlyreferred to as PCI.

It should be noted that some of the functional blocks described mightencompass multiple physical components. As well, multiple functionalblocks may be contained in a single physical component. It should alsobe noted that a stand-alone player 112 is not limited to thecapabilities and features listed in this description, but may contain asubset of the described features or may contain additional capabilitiesor features not listed.

Audio Gateway Software

FIGS. 16 to 20 provide flow diagrams for the audio gateway embodiment ofthis invention. In these flow diagrams, the software is assumed to berunning in a multitasking environment, with each of the flow diagramsrepresenting a particular independently running task or process.However, it should be noted that these flow diagrams represent only oneof many different ways to implement the key software functionality forthe audio gateway and that many other implementations are possible,including those which do not require a multitasking environment.

Audio Gateway Message Handling Flow

FIG. 16 provides the flow diagram of the message handler for the audiogateway. In general, the message handler takes the messages receivedfrom other computing platforms 103, mobile digital audio players 115,and fixed digital audio players 116 on the wireless network or wirelesscommunication platform 104 and queues these messages for use by otherprocesses or handles them itself, depending on the message type. In thisembodiment, the message handler is a continuously running process. Thestep, “Start” 200, represents the beginning of the message handlingprocess. The message handler checks if there is a message received instep 201.

If a message has been received, the message handler then checks to seewhat type of message it is, among many possible types, as indicated insteps 202-212. After the message handler determines the type of message,an appropriate response is queued and the system returns to step 201 andchecks for additional messages. If the message is a broadcast responsemessage from a player 202, then the message handler queues the broadcastresponse message 203. If the message is a query response message from aplayer 204, then the message handler queues the query response messagein step 205. If the message is a poll response message from a player206, then the message handler queues the poll response message in step207. If the message is a playlist response message from a player 208,then the message handler queues the playlist response message in step209. If the message is a content response message from a player 210,then the message handler queues the content response message in step211. If the message is a content acknowledge message from a player 212,then the message handler queues the content acknowledge message in step213. If the message was none of those previously checked for, themessage handler handles or queues any other messages as necessary 214.

Audio Gateway Discovery Flow

Discovery of mobile digital audio players 115 and fixed digital audioplayers 116 within range of the audio gateway, on the wireless networkor wireless communication platform 104, is an important capability withrespect to this invention. FIG. 17 provides the flow diagram fordiscovery by the audio gateway of mobile digital audio players 115 andfixed digital audio players 116. In this example, the audio gatewaydiscovery handler is a continuously running process. The step “Start”220, represents the beginning of the discovery handling process. Inorder to get a message response from the mobile digital audio players115 and fixed digital audio players 116, the discovery handler sends abroadcast for players message in step 221. The discovery handler thenwaits, with a timeout, for example, 5 seconds, for a broadcast responsemessage from any players in step 222. The discovery handler then checksif there is a player broadcast response message in the queue in step223. If there is no response, then the discovery handler broadcastsagain for players. If there is a response, then the discovery handlersends a query player message to a responding player in step 224 to getinformation about the type of player that has responded. The discoveryhandler then waits, with some timeout, for a player query responsemessage in step 225 from the player that previously responded to thebroadcast. The discovery handler then checks if there is a queryresponse message in the queue in step 226. If there is no response, thenthe discovery handler broadcasts again for players. If there is aresponse, then the discovery handler checks the information returned inthe query response message to see if the player is already known in step227. If the player is already known, then the discovery handlerbroadcasts again for players. However, a player is unlikely to respondto a broadcast from an audio gateway when the player and audio gatewayalready know about each other. If the player is not already known, thenthe discovery handler adds the player to the list of players inproximity in step 228 of the audio gateway. Finally, the discoveryhandler flags the new player in proximity for playlist continuation instep 229 and for content synchronization in step 230. This allows theplaylist continuation handler in the audio gateway to capture thecurrent playlist and current selection from this new player for possiblebroadcast to other players. Also, this allows the contentsynchronization handler in the audio gateway to automatically downloaddigital audio content and other information 101 cached on the audiogateway to the new player.

Audio Gateway Dropout Detection Flow

The flow diagram for audio gateway detection of dropout of players isshown in FIG. 18. The dropout detection handler in the audio gatewaypolls players that are known to be in proximity in order to see if anyof the players has possibly gone out of range of the wireless network orwireless communication platform 104 or has been turned off. In thisexample, the dropout detection handler is a continuously runningprocess. The step, “Start” 240, represents the beginning of the dropoutdetection handling process. The dropout detection handler checks thelist of players in proximity 241 maintained by the audio gateway. Ifthere are players in proximity as determined in step 242, then thedropout detection handler sends a poll message to the next player inproximity in the proximity list in step 243. This allows all the playersin the list of players in proximity to be checked in a sequentialmanner. Then the dropout detection handler waits, with some timeout, fora poll response message from the player in step 244 that was sent thepoll message in step 243. If there is no poll response message from theplayer in the queue in step 245 then the dropout detection handlerchecks if the player is already flagged as possibly being out of rangein step 246 of the wireless network or wireless communication platform104. If the player is not already flagged as possibly out of range 246,then the dropout detection handler flags that the player is possibly outof range in step 247 and checks the list of players in proximity again.If the player is already flagged as possibly out of range in step 246,then the dropout detection handler removes the player from the list ofplayers in proximity in step 248 and checks the list of players inproximity in step 241 again. If the player poll response message is inthe queue in step 245, then the dropout detection handler clears thepossibly out of range flag in step 249 for the player in the list ofplayers in proximity. Next, the dropout detection handler checks if theplayer is requesting content synchronization in step 250, based oninformation passed in the poll response message from the player. If theplayer is requesting content synchronization, then the dropout detectionhandler flags the player for content synchronization in step 251 in thelist of players in proximity. The content synchronization handler usesthis information when deciding which players to update for digital audiocontent and other information 101. Once the player is flagged forcontent synchronization or the player is not requesting contentsynchronization, then the dropout detection handler checks if the playeris requesting playlist continuation in step 252, based on informationpassed in the poll response message from the player. If the player isrequesting playlist continuation, then the dropout detection handlerflags the player for playlist continuation in step 253 in the list ofplayers in proximity. The playlist continuation handler uses thisinformation when deciding which players to update the playlist andcurrent selection for. Once the player is flagged for playlistcontinuation in step 253 or the player is not requesting playlistcontinuation in step 252, then the dropout detection handler checks thelist of players in proximity in step 241 again.

Audio Gateway Content Synchronization Flow

The flow diagram for audio gateway content synchronization is shown inFIG. 19, with content synchronization being a key capability of theinvention. The content synchronization handler in the audio gatewaychecks for players that need content synchronization. Contentsynchronization involves updating or adding digital audio content andother information 101 to a player when the audio gateway has digitalaudio content and other information 101 that is not contained on theplayer. This may be handled automatically when the player has recentlybeen discovered as being in proximity by the gateway discovery handleror the player directly requests content synchronization through pollresponse messages to the gateway. In this example, the contentsynchronization handler is a continuously running process. The step,“Start” 260, represents the beginning of the content synchronizationhandling process. The content synchronization handler checks the list ofplayers in proximity in step 261 maintained by the gateway. If there areplayers in proximity flagged for content synchronization in step 262,then the content synchronization handler sends a query player forcontent message to the player in step 263 that is flagged for contentsynchronization. Next, the content synchronization handler waits, withsome timeout, for a player content response message in step 264. Ifthere is no content response message in the queue in step 265 from theplayer that was sent the query player for content message in step 263,then the content synchronization handler clears the contentsynchronization flag for the player in the proximity list in step 266and checks the list of players in proximity again. If there is a contentresponse message in the queue in step 265 from the player that was sentthe query player for content message, then the gateway compares thedigital audio content in the player with the digital audio content inthe gateway in step 267. The player's digital audio content informationis contained in the content response message sent to the gateway by theplayer. Next, the content synchronization handler checks if there is anycontent in the gateway that is not on the player in step 268. If theplayer content is properly synchronized with the gateway, then thecontent synchronization handler clears the content synchronization flagfor the player in the proximity list and checks the list of players inproximity in step 261 again. If there is content on the gateway that isnot on the player in step 268, then the content synchronization handlerchecks if there is storage on the player for the new content in step269. The available storage on the player is provided in the contentresponse message that the player sent to the gateway. If there is notsufficient storage on the player for the new content in step 269, thenthe content synchronization handler clears the content synchronizationflag for the player in the proximity list in step 266 and checks thelist of players in proximity in step 261 again. If there is storage onthe player for the new content as determined in step 269, then thecontent synchronization handler sends the content data to the player instep 270. Next, the content synchronization handler waits, with sometimeout, for the content acknowledge message from the player in step271. If there is no content acknowledge message in the queue in step272, then the content synchronization handler clears the contentsynchronization flag for the player in the proximity list in step 266and checks the list of players in proximity in step 261 again. If thereis a content acknowledge message in the queue from the player, then thecontent synchronization handler checks to see, from the compare ofcontent in the player with content in the gateway, if there is morecontent to send to the player in step 273. If there is more content tosend to the player then the content synchronization handler checks againif there is storage on the player for the new content in step 269, andso on until there is no more content to pass from the gateway to theplayer. If there is no more content to send to the player, then thecontent synchronization handler clears the content synchronization flagfor the player in the proximity list in step 266 and checks the list ofplayers in proximity in step 261 again.

Audio Gateway Playlist Continuation Flow

The flow diagram for audio gateway playlist continuation is shown inFIG. 20, with playlist continuation being a key capability of theinvention. The playlist continuation handler in the audio gateway checksfor propagation of the playlist and current playlist selection from onemobile digital audio player 115 or fixed digital audio player 116 to allother mobile digital audio players 115 and fixed digital audio players116 in proximity. Playlist continuation involves seamless continuationof playback of digital audio content 101 from a particular playlist as auser moves from one mobile digital audio player 115 or fixed digitalaudio player 116 to another. This may be handled automatically when thegateway discovery handler discovers a player as being in proximity,where the player is currently playing digital audio content 101. Theplayer itself may also directly request playlist continuation throughpoll response messages to the gateway.

In this example, the playlist continuation handler is a continuouslyrunning process. The step, “Start” 280, represents the beginning of theplaylist continuation handling process. The playlist continuationhandler checks the list of players in proximity in step 281 maintainedby the gateway. If there are players in proximity flagged for playlistcontinuation in step 282, then the playlist continuation handler sends aquery player for playlist message to the player in step 283 that isflagged for playlist continuation. Next, the playlist continuationhandler waits, with some timeout, for a player playlist response messagein step 284. If there is no playlist response message in the queue instep 285 from the player that was sent the query player for playlistmessage in step 283, then the playlist continuation handler clears theplaylist continuation flag for the player in the proximity list in step286 and checks the list of players in proximity again. If there is aplaylist response message in the queue as determined in step 285 fromthe player that was sent the query player for playlist message in step283, then the gateway checks the playlist response message to see if theplaylist and current position within the playlist, both of which arecontained in the playlist response message, are valid in step 287. Ifthe playlist and current position are not valid, then the playlistcontinuation handler clears the playlist continuation flag for theplayer in the proximity list in step 286 and checks the list of playersin proximity again. If the playlist and current position in the playlistare valid as determined in step 287, then the playlist continuationhandler checks the list of players in proximity in step 288. If thereare any other players in proximity as determined in step 289, then theplaylist continuation handler sends a broadcast playlist and currentposition message to all other players in proximity in step 290. Afterthe playlist continuation handler sends a broadcast playlist and currentposition message to all other players in proximity in step 290 or ifthere are no other players in proximity, then the playlist continuationhandler clears the playlist continuation flag for the player in theproximity list in step 286 and checks the list of players in proximityin step 281 again.

Player Software

FIGS. 21-27 provide flow diagrams for the various digital audio players.In these flow diagrams, the software is assumed to be running in amultitasking environment, with each of the flow diagrams representing aparticular independently running task or process. However, it should benoted that these flow diagrams represent only one of many different waysto implement the key software functionality for the player and that manyother implementations are possible, including those which do not requirea multitasking environment.

Player Message Handling Flow

FIG. 21 is a flow diagram of the message handler for a player. Ingeneral, the message handler takes the messages received from computingplatforms 103 acting as audio gateways and from other mobile digitalaudio players 115 and fixed digital audio players 116, on a wirelessnetwork or wireless communication platform 104, and queues thesemessages for use by other processes or handles them itself, depending onthe message type. In this example, the message handler is a continuouslyrunning process. The step, “Start” 300, represents the beginning of themessage handling process. The message handler checks if there is amessage received in step 301. If there is a message received, themessage handler then checks to see what type of message it is, amongmany possible types.

After the message handler determines the type of message an appropriateresponse is queued and the system returns to step 301 and checks foradditional messages. If the message is a broadcast for players messagefrom a gateway as determined in step 302, then the message handlerqueues the broadcast for players message in step 303. After the messagehandler queues the broadcast for players message in step 303, themessage handler checks for more messages. If the message is a queryplayer message from a gateway as determined in step 304, then themessage handler queues the query player message in step 305. After themessage handler queues the query player message in step 305, the messagehandler checks for more messages. If the message is a poll message froma gateway as determined in 306, then the message handler queues the pollmessage in step 307. After the message handler queues the poll messagein step 307, the message handler checks for more messages. If themessage is a query player for content message from a gateway asdetermined in 308, then the message handler queues the query player forcontent message in step 309. After the message handler queues the queryplayer for content message in step 309, the message handler checks formore messages. If the message is content data from a gateway in step310, then the message handler stores the content in local player storagein step 311. The message handler also sends a content acknowledgemessage to the gateway in step 312. After the message handler sends acontent acknowledge message to the gateway in step 312, the messagehandler checks for more messages. If the message is a query player forplaylist message from a gateway as determined in step 313, then themessage handler queues the query player for playlist message in step314. After the message handler queues the query player for playlistmessage in step 314, the message handler checks for more messages. Ifthe message is a broadcast playlist message from a gateway as determinedin step 315, then the message handler queues the broadcast playlistmessage in step 316. After the message handler queues the broadcastplaylist message in step 316, the message handler checks for moremessages. Finally, if the message was none of those previously checkedfor, the message handler handles or queues any other messages asnecessary in step 317 and then the message handler checks for moremessages.

Player Discovery Flow

Discovery by the audio gateway of mobile digital audio players 115 andfixed digital audio players 116 is an important capability with respectto this invention. FIGS. 22 and 23 provide the flow diagrams fordiscovery responses by the player when the player detects discoveryattempts by an audio gateway. In this example, the player discoverybroadcast response handler and the player discovery query responsehandler are continuously running processes. The step, “Start” 320,represents the beginning of the discovery broadcast response handlingprocess. The discovery broadcast response handler first checks for abroadcast for players message in the queue in step 321 from a gateway.If there is a broadcast for players message in the queue as determinedin 322, then the discovery broadcast response handler checks if thegateway is already in proximity of the player in step 323. The discoverybroadcast response handler is able to get information about the gatewayfrom the broadcast for players message received from the gateway and cancompare that information with information saved by the discovery queryresponse handler for any gateway in proximity. If the gateway is notalready in proximity as determined in step 323, then the discoverybroadcast response handler sends a broadcast acknowledge message to thegateway in step 324. After the discovery broadcast response handlersends the broadcast acknowledge message to the gateway in step 324, orif the gateway is already in proximity as determined in step 323, or ifthere is no broadcast for players message in the queue as determined instep 322, then the discovery broadcast response handler checks for abroadcast for players message in the queue again.

The step, “Start” 330 (FIG. 23), represents the beginning of thediscovery query response handling process. The discovery query responsehandler first checks for query player messages from a gateway in thequeue in step 331. If there is a query player message in the queue asdetermined in step 332, then the discovery query response handler sendsa query response message to the gateway in step 333 that sent the queryplayer message. Then the discovery query response handler saves that thegateway is in proximity in step 334 from information obtained from thequery player message from the gateway. After the discovery queryresponse handler saves that the gateway is in proximity as determined instep 334 or if there is no query player message in the queue asdetermined in step 332, then the discovery query response handler checksfor a query player message from a gateway in the queue again.

Player Dropout Detection Flow

The flow diagram for player dropout detection of an audio gateway isshown in FIG. 24. The dropout detection handler in the player watchesfor poll messages from an audio gateway in order to see if the playerhas gone out of range of the gateway. In this example, the playerdropout detection handler is a continuously running process. Step,“Start” 340, represents the beginning of the player dropout detectionhandling process. The player dropout detection handler checks if theplayer is in proximity of a gateway in step 341. The player discoveryquery response handler, shown in FIG. 23, saves information about agateway that is in proximity. If the player is not in proximity of agateway as determined in step 341, then the player dropout detectionhandler just continues to check if the player is in proximity of agateway. If the player is in proximity of a gateway as determined instep 341, then the player dropout detection handler waits, with sometimeout, for a poll response message from the gateway in step 342 thatis in proximity. The timeout period is significantly more than thepolling period used by the gateway. If there is not a poll message inthe queue as determined in step 343 from the gateway that is inproximity, then the player dropout detection handler checks if thegateway is already flagged as possibly out of range in step 344. If thegateway is not already flagged as possibly out of range as determined instep 344, then the player dropout detection handler flags that thegateway is possibly out of range in step 345 and then continues to checkif the player is in proximity of a gateway in step 341. If the gatewayis already flagged as possibly out of range as determined in step 344,then the player dropout detection handler removes the gateway as beingin proximity in step 346 and then continues to check if the player is inproximity of a gateway in step 341. If there is a poll message in thequeue as determined in 343 from the gateway that is in proximity, thenthe player dropout detection handler checks if the user requestedcontent synchronization of the player in step 347. If the user didrequest content synchronization of the player as determined in step 347,then the player dropout detection handler flags a contentsynchronization request in the poll response message in step 348 to thegateway in proximity. If the user did not request contentsynchronization of the player, then the player dropout detection handlerskips flagging of content synchronization in the poll response messagein step 348. Next, the player dropout detection handler checks if theuser requested playlist continuation for the player in step 349. If theuser did request playlist continuation for the player as determined instep 349, then the player dropout detection handler flags a playlistcontinuation request in the poll response message in step 350 to thegateway in proximity. If the user did not request playlist continuationfor the player as determined in step 349, then the player dropoutdetection handler skips flagging of playlist continuation in the pollresponse message in step 350. Next, the player dropout detection handlersends the poll response message to the gateway in step 351 that is inproximity and sent the poll message. Next, the player dropout detectionhandler clears the gateway possibly out of range flag in step 352 if itwas set for the gateway in proximity. Then the player dropout detectionhandler continues to check if the player is in proximity of a gateway asdetermined in step 341.

Player Content Synchronization Flow

The flow diagram for player content synchronization response is shown inFIG. 25, with content synchronization being a key capability of theinvention. The content synchronization response handler in the playerresponds to content queries from a gateway. In this example, the contentsynchronization response handler is a continuously running process. Thestep, “Start” 360, represents the beginning of the contentsynchronization response handling process. The content synchronizationresponse handler checks for a query player content message in the queuein step 361 from a gateway. If there is a query player content messagein the queue as determined in step 362, then the content synchronizationresponse handler builds a content response message by first getting alist of all the digital audio content on the player in 363. Next, thecontent synchronization response handler determines the amount ofavailable storage space on the player in step 364 for additional digitalaudio content. Finally, the content synchronization response handlersends a player content response message in step 365 to the gateway thatsent the query player content message. The player content responsemessage contains the list of all the digital audio content on the playeras well as the amount of available space on the player. Once the contentsynchronization response handler sends a player content responsemessage, as determined in step 365, to the gateway that sent the queryplayer content message or there is no query player content message inthe queue in step 362, then the content synchronization response handlerchecks for a query player content message in the queue again.

Player Playlist Continuation Flow

FIGS. 26 and 27 represent flow diagrams for playlist continuationresponse and playlist continuation updating by the player when theplayer detects playlist continuation query and updating attempts by anaudio gateway. Playlist continuation is a key capability of theinvention. In this example, the player playlist response handler and theplayer playlist update handler are continuously running processes. Thestep, “Start” 380, represents the beginning of the playlist responsehandling process. First, the playlist response handler checks for aquery player for playlist message in the queue in step 381 from agateway in proximity. If there is a query player for playlist message inthe queue as determined in step 382, then the playlist response handlergets the current playlist and current position within the playlist instep 383 and puts this information in a playlist response message. Next,the playlist response handler sends the playlist response message to thegateway in step 384 that sent the query player for playlist message.After the playlist response handler sends the playlist response messageto the gateway as determined 384 or there is not a query player forplaylist message in the queue as determined in step 382, then theplaylist response handler checks for a query player for playlistsmessage 381 in the queue again.

The step, “Start” 390 (FIG. 27), represents the beginning of theplaylist update handling process. First the playlist update handlerchecks for a broadcast playlist message in step 391 in the queue from agateway in proximity. If there is not a broadcast playlist message inthe queue as determine in step 392, then the playlist update handlerjust checks for a broadcast playlist message in the queue again. Ifthere is a broadcast playlist message in the queue, as determined instep 392, then the playlist update handler checks if the playlistalready exists on the player in step 393. The playlist information isfound in the broadcast playlist message. If the playlist already existson the player, as determined in step 393, then the playlist updatehandler activates the playlist and sets the current position within theplaylist in step 394 on the player. The current position within theplaylist is found in the broadcast playlist message. Then the playlistupdate handler checks for a broadcast playlist message in step 391 inthe queue again. If the playlist does not already exist on the player asdetermined in step 393, then the playlist update handler saves the newplaylist on the player in step 395. Next, the playlist update handlerchecks if the player is currently playing in step 396. If the player isnot currently playing, then the playlist update handler sets the newplaylist as the current playlist in step 397 and sets the currentposition within the playlist in step 394. If the player is currentlyplaying, then the playlist update handler notifies the user that a newplaylist is available in step 398. This allows the user to decide toplay the new playlist or continue with a current playlist. Next, theplaylist update handler checks for a broadcast playlist message in step391 in the queue again.

Obviously, many modifications and variations of the present inventionare possible in light of the above teachings. Thus, it is to beunderstood that, within the scope of the appended claims, the inventionmay be practiced otherwise than as specifically described above.

What is claimed and desired to be covered by a Letters Patent is asfollows:

We claim:
 1. A digital gateway device comprising: a system bus; amicroprocessor coupled to said system bus; one or more storage devicescoupled to said system bus; a wireless communications platform forestablishing a communication link with one or more external devices; andwireless interface for establishing a communication link with externalsources of digital content.